在 Kube-apiserver 中提供了很多认证方式，其中最常用的就是 TLS 认证，当然也有 BootstrapToken，BasicAuth 认证等，只要有一个认证通过，那么 Kube-apiserver 即认为认证通过。下面就主要讲解 TLS 认证。

如果你是使用 kubeadm 安装的 Kubernetes， 则会自动生成集群所需的证书。但是如果是通过二进制搭建，所有的证书是需要自己生成的，这里我们说说集群必需的证书。

在了解 Kubernetes 证书之前，需要先了解什么是 “单向 TLS 认证” 和 “双向 TLS 认证”

Kubernetes 为了安全性，都是采用双向认证。通常我们使用 Kubeadm 在部署 Kubernetes 时候，Kubeadm 会自动生成集群所需要的证书，下面我们就这些证书一一给大家进行讲解。

这是我们用 Kubeadm 搭建完一个集群后在 /etc/kubernetes 目录下所生成的文件

下面我们根据这个 Kubernetes 的组件之间通讯图来一一讲解每个证书的作用。本文基于 Kubernetes:v1.22.17

Kubeadm 安装的集群中我们都是用 3 套 CA 证书来管理和签发其他证书，一套 CA 给 ETCD 使用，一套是给 Kuberntes 内部组件使用，还有一套是给配置聚合层使用的，当然如果你觉得管理 3 套 CA 比较麻烦，您也可以用一套来管理。

etcd 证书位于 /etc/kubernetes/pki/etcd 目录下，我们根据 etcd 的 static-pod yaml 配置解释下证书的作用

Etcd 根证书用于签发其余证书，比如服务端证书，客户端证书等

Etcd 对外提供服务的服务器证书及私钥，比如 etcd-ctl 访问 Etcd 的时候就会用 ca.crt 去验证 server.crt

Etcd 启动时通过 - --cert-file=/etc/kubernetes/pki/etcd/server.crt，- --key-file=/etc/kubernetes/pki/etcd/server.key 来配置服务端证书可私钥

Etcd 节点之间相互进行认证的 peer 证书、私钥，结点之间心跳检测，数据同步等通信都会使用 peer.crt 来验证

通过 - --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt，- --peer-key-file=/etc/kubernetes/pki/etcd/peer.key 来配置

探测 Etcd 服务健康检查接口，客户端会下载服务端证书进行验证，服务端也会下载客户端证书验证，即下面的客户端证书，这个需要客户端来配置

Kube-apiserver 证书位于 /etc/kubernetes/pki ，同样我们通过 Kube-apiserver 的 static-pod yaml 文件来一一解释下每个证书的作用。

用来签发 Kubernetes 中其他证书的 CA 证书及私钥，Kube-apiserver 会配置自己的根证书，也会配置 etcd 的根证书，是因为 Kube-apiserver 会作为客户端去访问 Kubelet，需要 ca.crt 来验证 Kubelet 的服务端证书，而且 Kube-apiserver 也会作为客户端去访问 Etcd，因为 Etcd 与 Kubernetes 不同属一个根证书，所以配置两个不同 CA。

通过 - --client-ca-file=/etc/kubernetes/pki/ca.crt，- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt 分别配置

Kube-apiserver 对外提供服务的证书及私钥，通过 --tls-cert-file=/etc/kubernetes/pki/apiserver.crt，--tls-private-key-file=/etc/kubernetes/pki/apiserver.key 配置

假如 Kube-apiserver 自定义对外访问时，要在服务端证书的 SANs（Subject Alternative Name) 字段中添加对应的 DNS名称 或 IP地址，否则客户端会因访问地址与证书不匹配而报错。kubeadm 会帮我们设置一些默认的 SANs，包括 master 结点 IP，Kube-apiserver SVC IP 等。可以通过 openssl 命令查看证书的 SANs

可以看到在 Subject Alternative Name 字段中，已经包含了一些默认的 Kube-apiserver 访问 DNS 或者 IP。

Tips： 当我们使用 kubeadm 创建集群时候，可以在init时使用 --apiserver-cert-extra-sans 参数指定 SANs，kubeadm 会在生成证书时在默认的基础上增加设置的 SANs。

前面说过 Kubernetest 组件间访问都是采用双向 TLS 认证，所以 Kube-apiserver 访问 Etcd 的时候，Kube-apiserver 回去校验 Etcd 服务端证书，同时 Etcd 也会校验 Kube-apiserver 的客户端证书，达到双向认证。因为 Etcd 服务端证书是有 Etcd 的根证书签发，所以 Kube-apiserver 需要配置该 CA，通过 --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt 配置。Etcd 校验 Kube-apiserver 的客户端证书时，Kube-apiserver 会把该证书发送给 Etcd，通过 --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt，--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key 配置。

Kube-apiserver 也会去访问 Kubelet，例如 kubectl 查看 pod 日志，或者进入 pod 内部。和访问 Etcd 一样，Kube-apiserver 访问 Kubelet 也是双向 TLS 认证，Kube-apiserver 校验 Kubelet 的服务端证书，通过 --client-ca-file=/etc/kubernetes/pki/ca.crt，Kubelet 校验 Kube-apiserver 通过 --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt，--kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key。

要扩展 Kube-apiserver 的 API 时，可以采用 Kube-apiserver 聚合功能，具体 Kube-apiserver 聚合原理参考 https://kubernetes.io/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/

这里简单说明下请求链路，当使用 kubectl 对扩展 API 发起请求时，首先 Kube-apiserver 收到请求对 kubectl 使用的 Kube-config 进行认证、鉴权，通过后将请求转发给 APIAggregator，APIAggregator 可以理解为一层代理，然后 APIAggregator 根据 API 的 GroupVersion 来将请求转发给扩展 apiserver，所以 APIAggregator 与开发者开发的扩展 apiserver 就需要进行 TLS 认证。

理想情况扩展 apiserver 需要自己签发 CA，然后使用该 CA 签发服务端证书，服务端证书由扩展 apiserver 程序使用，CA 通过 APIService 资源来发布告知 Kube-apiserver APIAggregator ，然后 APIAggregator 访问时获取 APIService 的 caBundle 字段来认证扩展 apiserver。--requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt 来校验，同时扩展 apiserver 也会校验 APIAggregator 的客户端证书，APIAggregator 的客户端证书通过 --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt，--proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key 配置，扩展 apiserver 会通过 kube-system 命名空间下的 extension-apiserver-authentication configmap 获取签发 front-proxy-client.crt 的 CA，即 --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt ，Kube-apiserver 启动时会将该 CA 信息写入 extension-apiserver-authentication configmap 中。这样就达到双向 TLS 认证的效果。但是扩展 apiserver 也可以关闭服务端校验，通过 APIservice 的配置 insecureSkipTLSVerify: true ，这样就只会扩展 apiserver 校验 APIAggregator 了。

上面所说的证书都在 /etc/kubernetes/pki 目录下，除了 sa.pub 和 sa.key，这个下文讲解。在 Kubernetes 集群中，Kube-controller-manager 和 Kube-scheduler，Kubelet，Kubectl 都是通过 KubeConfig 来访问 Kube-apiserver，原理上都是证书，下面详细讲解下。

还是和之前一样，我们通过 kube-controller-mananger 的 yaml 文件配置来看看是如何访问 Kube-apiserver。

你会发现在 yaml 中配置了 /etc/kubernetes/controller-manager.conf 这个配置文件，而不是配置 controller-manager 的客户端证书之类的。Kubernetes 这里的设计是这样的，kube-controller-mananger、kube-scheduler、kubelet 等组件，采用一个kubeconfig 文件中配置的信息来访问 Kube-apiserver。该文件中包含了 Kube-apiserver 的地址，验证 Kube-apiserver 服务器证书的 CA 证书，自己的客户端证书和私钥等访问信息，这样组件只需要配置这个 Kubeconfig 就行。

下面我们看看 controller-manager.conf 这个文件配置的证书和秘钥是什么。

我们解析下 certificate-authority-data 这个内容看看是不是 Kubernetes 的 CA 的证书

从解码可以发现，Kubeconfig 配置的就是 Kubernetes 的 CA 证书，client-certificate-data 和 client-key-data 就是 Kube-controller-manager 用来访问 Kube-apiserver 的客户端证书和秘钥，只不过 Kubeconfig 对内容进行了 base64 编码。这个就是整个 Kube-controller-manager和 Kube-apiserver 证书认证的方式。

Kube-scheduler 也是同样的原理，也是在 yaml 中配置一个 Kubeconfig 来进行访问 Kube-apiserver

同理，解析 certificate-authority-data 也是 Kubernates 的 CA 证书，client-certificate-data 和 client-key-data 就是 Kube-scheduler 用来访问Kube-apiserver 的客户端证书和秘钥

Kubelet 与 Kube-apiserver 一样，即可以作为服务端，又可以作为客户端，所以分类讲解

Kubelet 和其他组件类似，用的 Kubeconfig 与 Kube-apiserver 进行认证、鉴权的，都是用 Kubernates 的 CA 签发。

这边我们会给每个节点生成一份客户端的证书和私钥，直接指向一个 kubelet-client-current.pem 文件，这里包含了证书和私钥，每一个节点都不一样。因此每个节点都会有一个自己的客户端证书和私钥。

Kubelet 客户端证书可以被自动续签，上面的证书期限都是固定的，下面具体续签的原理

Kubernetes 提供了一套证书相关的 API(Certificate API），用于实现证书的申请与自动签发。证书的申请者，如 Kubelet，可以通过创建一个 CSR资源来向指定的证书签名者（由 CSR 的 singerName 字段指定）申请证书签名，CSR 请求可能被批准，也可能被拒绝。当 CSR 请求被批准后，对应的证书签名者才会对证书签名，并将签名后的证书保存在 CSR 的 status.Certificat 字段中，至此整个签发流程就完成了。证书的申请者可以从 status.Certificate 中获取已经签名的证书。Kube-controller-manager 内置了一些签名者，分别处理对应 singerName 的 CSR 请求：

Kubelet 进行客户端证书轮换时，创建的 CSR 中的 singerName 就是 kubernetes.io/kube-apiserver-client-kubelet，正常情况下，会被 Kube-controller-manager 自动批准，然后签发证书。

当 CSR 提交后，需要由审批者（可以是人，也可以是程序）批准后才能进行后续的证书签发操作。Kube-controller-manager 内置了一个审批控制器，可以自动批准某些 CSR 请求。但为了防止与其他的审批者发生冲突，Kube-controller-manager 不会显式的拒绝任何 CSR。对于不会被Kube-controller-manager 处理的 CSR，我们可以使用 API 的方式处理，如实现一个专门的控制器来来自动批准或拒绝，或者使用 Kubectl 命令行：

对于 kubernetes.io/kube-apiserver-client-kubelet 类型的 CSR，Kube-controller-manager 根据申请者是否具备对应的 RBAC 权限，来决定是否批准该 CSR。Kubelet 在两种情况下都会创建 CSR 请求：

1、在首次加入集群时，还没有生成客户端证书，Kubelet 需要创建 CSR 资源来申请，这个阶段也就是 TLS 引导阶段。

2、当客户端证书快过期时，Kubelet 会发起证书轮换，创建 CSR 请求申请新的证书。

对于这两种场景，Kubernetes 提供了两个默认权限（ClusterRole）：

1、nodeclient：当节点首次创建证书时，Kubelet 还没有正式的客户端证书，处于 TLS 引导阶段。此时Kubelet 会使用 bootstrap token 认证方式来请求 Kube-apiserver。kubeadm init创建的 bootstrap token 所属用户组为 system:bootstrappers:kubeadm:default-node-token，kubeadm 会负责将 nodeclient 权限赋予该用户组。

2、selfnodeclient：当节点请求证书轮换时，Kubelet 已经有一个正式的客户端证书。Kubelet 的证书属于 system:nodes 用户组，kubeadm 会负责将 selfnodeclient 权限赋予该用户组。

当 CSR 请求被批准后，签发者才可以签发证书。Kube-controller-manager 同样也内置了签发控制器。通过为 Kube-controller-manager 设置 --cluster-signing-cert-file 和 --cluster-signing-key-file 启动参数以开启内置的签发控制器，这两个参数分别表示用于签名的证书和私钥，也就是集群的 CA 证书。

在1.18之前，kube-controller-manager会为所有已经批准的CSR签发证书。1.18之后，kube-controller-manager限制了CSR的singerName，只会为上述的四种指定singerName的CSR请求签发证书。类似的，对于不会自动签发证书的CSR请求，我们同样可以通过kubectl来手动签发，亦或者通过实现一个专门的控制器来自动签发。

Kube-controller-manager 通过配置 Kubelet 客户端证书续签周期 --experimental-cluster-signing-duration=87600h0m0s，来开启自动续签 Kubelet 客户端证书

Kubelet 同样对外暴露了 HTTPS 服务，其客户端主要是 Kube-apiserver 和一些监控组件，如 metric-server。Kube-apiserver 需要访问 Kubelet 来获取容器的日志和执行命令（kubectl logs/exec)， 监控组件需要访问 Kubelet 暴露的 cadvisor 接口来获取监控信息。理想情况下，我们需要将 Kubelet 的 CA 证书配置到 Kube-apiserver 和 metric-server 中，以便于校验 Kubelet 的服务端证书，保证安全性。但使用默认的集群设置方法是无法做到这点的，需要做一些额外的工作。

Kubernetes 中除了 Kubelet 的服务端证书以外，其他证书都要由集群根 CA（或是基于根CA的中间CA）签发。 Kubelet 的证书则没有这个要求。实际上，在 Kubelet 在启动时，如果没有指定服务端证书路径，会创建一个自签的 CA 证书，并使用该 CA 为自己签发服务端证书。

Kubelet 服务端证书和客户端证书生成逻辑不一样，有以下三种情况，可自选：

前面两种情况就会导致每个节点的 Kubelet 的根 CA 可能都不一样，这就导致客户端组件，如 metric-server ，Kube-apiserver 都没办法校验 Kubelet 的服务端证书。为了应对这种情况，metric-server 需要添加 *--kubelet-insecure-tls* 来跳过服务端证书的校验，而 Kube-apiserver 默认不校验 Kubelet 服务端证书。

第三种情况是 CSR 签发者统一用集群的根 CA 为各 Kubelet 签发服务端证书，Kube-apiserver 和其他组件就可以通过配置集群根 CA 来实现 HTTPS 的服务端证书校验了。我们可以在 Kubelet 配置文件配置 *serverTLSBootstrap = true* 就可以启用这项特性，使用 CSR 来申请服务端证书。这项配置同样也会开启服务端证书的自动轮换功能。不过这个过程并不是全自动的，在 CSR(CertificateSigningRequest) 章节中提到，Kubelet 的服务端证书 CSR 请求，即 *singerName* 为 *kubernetes.io/kubelet-serving* 的 CSR 请求，不会被 Kube-controller-manager 自动批准，也就是说我们需要手动批准这些 CSR，或者使用第三方控制器。

为什么 Kubernetes 不自动批准 Kubelet 的服务端证书呢？这样不是很方便吗？原因是出于安全考量—— Kubernetes 没有足够的能力来辨别该 CSR 是否应该被批准。

HTTPS 服务端证书的重要作用就是向客户端证明“我是我”，防止有人冒充“我”跟客户端通信，也就是防止中间人攻击。在向权威 CA 机构申请证书时，我们要提供一系列证明材料，证明这个站点是我的，包括要证明我是该站点域名的所有者，CA 审核通过后才会签发证书。但 K8S 集群本身是没有足够的能力来辨别 Kubelet 身份的，因为节点 IP，DNS 名称可能发生变化，K8S 自身没有足够的能力判断哪些 IP，哪些 DNS 是合法的，这属于基础设施管理者的职责范围。如果你的集群是云厂商提供，那么你的云厂商可以提供对应的控制器来判断 CSR 请求的合法性，批准合法的 CSR 请求。如果是自建集群，那么只有集群管理员才能判断 CSR 请求中包含的节点 IP，DNS 名称是不是真实有效的。如果 Kube-controller-manager 自动签发这些证书，则会产生中间人攻击的风险。

假设节点 A 上的服务 bar 使用 HTTPS 暴露服务，并且服务端证书是通过 CSR 请求申请的，由集群根 CA 签发。假设有入侵者获取了节点 A 的权限，那他可以很方便的利用 Kubelet 的客户端证书的权限，创建一个 CSR 请求来申请一份 IP 为 bar service IP，DNS 名称为 bar service DNS 的服务端证书。如果 Kube-controller-manager 自动通过并签发这个证书，那入侵者就可以使用这个证书，配合节点上的 Kube-proxy，劫持所有经过 bar 服务的流量。

在 Kubernetes 集群内部访问 Kube-apiserver 使用的是 Service Account ，如 pod 访问 Kube-apiserver

在 /etc/kubernetes/pki 目录下，还有 sa.pub，sa.key 这两个文件没有讲解。这两个就是用于 ServiceAccount 认证的，这两个文件是一对密钥对，sa.pub 代表公钥，sa.key 代表私钥。

Kubernetes 集群中还有个重要的系统组件 Kube-proxy，它也需要访问 Kube-apiserver，但是它和 Kube-controller-manager，Kube-scheduler 不一样，它就是使用 ServiceAccount 来与 Kube-apiserver 进行认证，下面详细看看。

当 Kube-proxy pod 在集群中创建时，如果 Pod 没有指定 ServiceAccount，kube-controller-manager 会默认创建一个没有任何权限的 ServiceAccount，同时 Kube-controller-manager 为该 ServiceAccount 生成一个 JWT token，并使用 secret 将该 token 挂载到 Pod 内部。

下面看看 secret 的内容

Kube-controller-manager 用 sa.key 即私钥对该 token 进行签名。当 Pod 需要访问 Kube-apiserver 的时候，认证逻辑如下：

这样就达到了 Pod 与 Kube-apiserver 双向认证(这里不是双向 TLS 认证)，所以 ServiceAccount 这种认证方式属于 Kube-apiserver 的 Token 认证。

下面是 ServiceAccout 认证流程图：

sa.pub 和 sa.key 分别被配置到了 Kube-apiserver 和 Kube-controller-manager 的命令行参数中，如下所示：

Kubernetes 证书系统还是比较复杂的，主要是涉及到双向 TLS 认证，但是只要能够弄清楚组件之间相互调用的关系以及双向 TLS 认证原理，就比较容易弄明白 Kubernetes 证书了。

以上主要是分析了 Kubernetes 集群中所有的证书和组件如何使用证书的，对于 Kube-apiserver 来说，我们只分析了 Kube-apiserver 如何根据证书进行认证，后续如何根据证书进行鉴权还没说。由于本篇篇幅较大，证书鉴权内容留到下一篇~

https://juejin.cn/post/7016472622246395934